This invention relates generally to computer systems, and more particularly to a method and apparatus for facilitating communication by objects across a network.
For a number of years now, the computing model that has been used predominantly in large companies has been the client-server model. According to this model, a plurality of clients are connected to one or more data servers via a network to form an overall centralized system. In a client-server system, each of the clients is responsible for storing and executing whatever applications are to be run on that client, while the servers are primarily used as central repositories for storing and managing data generated and used by the applications. The main advantage of a client-server system is that it allows data to be stored in a centralized location, thereby making it possible for multiple clients to access the same data. The major disadvantage of this type of system is high cost. Because each client is required to have sufficient capability to store and to execute applications (many of which can be resource intensive), each client is typically required to be a high power, and hence, relatively high cost machine (i.e. a xe2x80x9cfatxe2x80x9d client). Also, because each client maintains its own set of applications, the cost of maintaining the system can be quite high. Each application on each client must be set up and configured individually, and each client, in the event of a software upgrade, must be upgraded individually. For a large company with a large number of client machines, the cost of maintaining the system can be exorbitant.
Because of the high cost associated with client-server systems, there has been a trend in recent years towards a xe2x80x9cthin clientxe2x80x9d model of computing. According to this model, much of the processing burden is moved off of the clients onto a centralized application server. The application server is coupled to a plurality of clients via a network, and is responsible for storing and executing the applications requested by those clients. In a thin client system, the application server may also serve as the central data repository, or it may be coupled to a data server which serves as the central data repository, thereby giving rise to a three-tier architecture. Whatever form the overall system takes, the clients in a thin client system are relieved of most of the application execution burden. Primarily, the clients are responsible for rendering the user interface (UI) and performing other relatively simple functions. Because the clients are required to perform only relatively simple tasks, they may take the form of simple, low cost machines having minimal processing and storage capabilities. This gives rise to one of the main advantages of a thin client system, which is that of reduced cost. Because each client may be a low cost machine, the overall equipment cost of the system is significantly reduced. Also, because the applications are stored and executed in a centralized application server, the system is much simpler to maintain. Only the application server needs to be configured for each application, and only the application server needs to be upgraded. As a result, a thin client system is much more economical to implement and to maintain than a client-server system.
A thin client system provides significant cost advantages; however, these advantages come at the expense of increased network traffic. Because most of the application logic processing is performed by the application server, but all of the user input/output is received/rendered by the client, a significant amount of communication is conducted between the client and the application server. This communication is conducted across a network, which is a limited and scarce resource. In any computer implementation involving a network, one of the utmost concerns is that of minimization of network traffic. With excessive traffic, a network can quickly become the bottleneck of the entire system. Hence, for any application that is designed to run in a thin client environment, it is necessary for the application to manage communications across the network efficiently so that the network is not overly burdened.
One approach that has been taken to limit network traffic involves the implementation of a specific protocol between the client and the server using two separate processes, one process executing on the client and the other process executing on the server. These processes, which are specifically designed to understand messages from the other process, perform two main functions. First, each process interprets messages received from the other process to carry out functions indicated by those messages. For example, the client process receives messages from the server process indicating which items to render on the display. In response, the client process interprets the messages and renders the appropriate items. Because the processes are specifically developed to understand each other""s messages, a very streamlined protocol can be implemented to minimize the amount of information that needs to travel across the network. A second function performed by the processes is the minimization of the number of messages that are sent across the network. This is typically achieved by bundling a plurality of sets of information into a single message. By putting multiple sets of information into a single message, the number of messages that need to be sent across the network is minimized. This approach has been implemented both in applications and in tools for facilitating the development of applications to minimize network traffic.
The above approach is effective for controlling network traffic; however, it achieves network performance at the expense of flexibility. One of the major drawbacks of this approach is that it does not allow users to freely define their own UI items. They may utilize only the items that the two processes have been designed and hard coded to recognize. For example, if the client and server processes know how to render a certain UI button, but the user needs to render a new customized UI button, the user will not be able to render the customized button unless the code for the client and server processes are altered. If the user has access to the source code, this may not be an overly burdensome process. However, if the user does not have access to the source code, which is often the case, especially in the tools arena, then the user would have to submit a request to the tools vendor to change the code. If the vendor agrees to make the change, then the vendor would have to go through the design and implementation process to effect the change. Thereafter, the vendor would have to release a new version of the software with the changes incorporated therein. This process could take several months, which is much too long to be practicable. As a result, the above approach is too rigid for many implementations.
A much more flexible and desirable approach to implementing a UI is the object oriented approach. Under this approach, the UI is composed of a plurality of independent objects, each object capable of independent operation and communication with the server, and each object capable of invoking the methods of other objects. In the object oriented paradigm, because each object is an independent entity, it is a relatively simple matter to: (1) replace one object with another; and (2) add new object classes. For example, if the user wishes to render a new type of button in the UI, the user simply defines the new type of button, and then starts using that new button in the UI. There is no need to enlist the aid of a tools vendor. Because it is so flexible and extensible, the object oriented paradigm is the preferred approach for implementing UI""s.
One problem with implementing an object oriented paradigm in a networked environment, however, is that it tends to create a high volume of network traffic. As noted above, each object is an independent entity responsible for its own communication. This means that each time an object needs to send a message to the server, it incurs a network round trip. With a relatively large number of objects, this can quickly generate enough traffic to choke most networks. Despite its impracticability, this approach is the one set forth by the Common Object Request Broker Architecture (CORBA) and the Java Remote Method Invocation (RMI) standards. Although implementing an object oriented paradigm is difficult in a networked environment, it is still quite desirable because it provides a richness and a robustness that cannot be matched by other approaches, especially in the graphical user interface (GUI) arena. Thus, the challenge is to develop a mechanism which enables an object oriented paradigm to be implemented in a networked environment without causing the network to be overburdened.
The present invention provides a novel and advantageous framework for enabling an object oriented paradigm to be implemented effectively in a networked environment. The framework provides the necessary structure for controlling and managing the communications of the objects to prevent the objects from overloading the network with excessive traffic. At the same time, the framework does not limit, but rather works with the independent nature of the objects to carry out the control and management functions. By providing structure without sacrificing the flexibility, extensibility, and robustness of object oriented technology, the framework of the present invention provides a complete solution to the challenge posed above.
According to one embodiment, there is provided a pair of objects for managing the flow of information between the server and the client. These objects include a client dispatcher object which executes on the client, and a server dispatcher object which executes on the server. Each dispatcher is responsible for managing the network communication of the objects on its side. That is, the client dispatcher is responsible for managing the network communication of the objects on the client side, while the server dispatcher is responsible for managing the network communication of the objects on the server side. The client dispatcher object and the server dispatcher object communicate with each other using an underlying network communication mechanism, such as a CORBA object request broker (ORB), which allows method calls to be made across a network. The primary responsibility of these dispatchers is to manage the flow of messages between the client and the server. Specifically, each of the dispatchers is responsible for: (1) collecting messages from a plurality of associated objects and assembling them into a batch; (2) sending the messages as a batch across the network to the other dispatcher; (3) receiving a message batch from the other dispatcher; (4) extracting the individual messages from the message batch; and (5) distributing the individual messages to the associated objects to which the messages are intended. By collecting and sending messages in batches, the dispatchers minimize the number of network round trips that need to be incurred, thereby minimizing network traffic.
The present invention further provides a mechanism for facilitating communication between the dispatchers and their associated objects. This mechanism is needed by the dispatchers in order to manage the network communications of their associated objects. In one embodiment, this mechanism takes the form of an interface referred to herein as xe2x80x9cproxyxe2x80x9d. The proxy interface sets forth a set of methods that each of the associated objects needs to implement in order to participate in the communication scheme of the present invention. The methods of the proxy interface are invoked by the dispatchers to communicate with the individual associated objects. Note that the proxy interface merely specifies the methods that each of the associated objects should implement. It does not provide any specific implementation for any of the methods. It will be up to each of the associated objects to provide its own implementation for each of the specified methods (i.e. to implement proxy). The implementations provided by each object may be different, so that each object may customize its own behavior.
In operation, the framework is used as follows. Whenever an object on the client side (a client object) wishes to send a message to a peer object on the server side (a server object), the client object sends the message to the client dispatcher. The client dispatcher stores the message into a buffer. The client dispatcher continues to store messages from client objects into the buffer until it is instructed by one of the client objects, such as a coordinator object, to incur a network round trip. Once that occurs, the client dispatcher sends the messages stored in the buffer across the network as a batch to the server dispatcher. In response, the server dispatcher parses the individual messages from the message batch, and distributes them to the server objects for which they are intended. In performing the distribution function, the server dispatcher invokes the proxy interface implementations of the server objects.
Thereafter, the server objects process the messages and perform whatever functions are needed in response to the messages. Once the processing is performed, the server objects generate return messages for their peer client objects. These messages are then sent to the server dispatcher. The return messages are stored by the server dispatcher into a buffer, and then sent as a batch across the network to the client dispatcher. In response, the client dispatcher parses the individual messages from the message batch, and distributes them to the client objects for which they are intended. In performing the distribution function, the client dispatcher invokes the proxy interface implementations of the client objects. In this manner, messages between objects are efficiently transferred across the network.
Several points should be noted with regard to the present invention. First, note that rather than incurring a round trip for each message, the objects send their messages to a corresponding dispatcher. In turn, the dispatchers collect the messages, and send them across the network in the form of a batch. By doing so, the dispatchers limit the number of round trips that are taken across the network, thereby minimizing network traffic. Thus, the framework of the present invention provides the necessary structure for keeping network traffic to a minimum. At the same time, the framework does not impose limits on the functionality of the individual objects. The user is free to impart whatever functionality he wishes to each object, and each object is allowed to behave as an independent object. As a result, each object may be easily replaced with another object, and new object classes may be easily added. If a user needs a new type of object (e.g. a new type of UI button), all he needs to do is to create the new object type and to start using it. There is no need to go back to any tools vendor. So long as the new object type provides an implementation for the proxy interface, it will be able to participate in the communication scheme of the present invention.
In effect, the framework of the present invention separates the communication aspect of an object from the functional aspect. The framework provides the structure needed to effectively manage the communication aspect to minimize network traffic, but leaves the functional aspect completely up to the developer. By separating these two aspects, the framework makes it possible to both manage network traffic and to take full advantage of the flexibility, extensibility, and richness offered by object orient technology. Thus, the present invention provides an effective mechanism for implementing an object oriented paradigm in a networked environment.